1. Field of the Invention
The present disclosure relates generally to techniques for triangle culling in pipelined 3D graphic engines and was developed by paying specific attention to the possible application to graphic engines that operate in association with graphic languages.
Exemplary of such an application are the graphic engines operating in association with e.g., OpenGL, NokiaGL and Direct3D, in particular but not exclusively in mobile phones.
However, reference to this preferred application is in no way to be construed as limiting the scope of the invention.
2. Description of the Related Art
Modern 3D graphic pipelines for graphic engines in graphic cards include a rich set of features for synthesizing interactive three-dimensional scenes with a high and realistic quality.
Nowadays, in order to output frame-rates ranging from 30 to 100 frames per second, powerful dedicated graphic cards are required having correspondingly high costs. The number of pictures per time unit is increased usually by parallelizing—inasmuch as possible—all the operations involved in the process of designing in the frame buffer those graphic objects that are to be displayed while at the same time increasing the computational power available by performing at higher speeds those operations that cannot be parallelized.
A description of an OpenGL pipeline for 3D interactive graphics is given in a co-pending European Patent application filed on the same day and in the name of one of the Applicants herein, entitled “Graphic system comprising a pipelined graphic engine, pipelining method and computer program product”. Such a patent application, whose contents are herein incorporated by reference, describes graphical operations performed in a geometry stage comprised in the graphic engine. In particular, a back-face culling operation is described.
In the back-face culling operation, it is very convenient to cull the triangles at an earlier stage of the pipeline since this will appreciably decrease the “potentially visible triangles” submitted to later stages and the processing needed. Assuming that a 3D model is composed by triangles within the unit cube (which means that they are potentially visible), triangles can be of two types: those triangles that are visible for the observer and those that are not visible. “Back-face culling” is able to remove from the list of potentially visible triangles those of “back-face” type. For symmetric objects, 50% of the triangles are front facing and the other 50% are back facing. The ability of removing 50% of the triangles leads to avoiding all subsequent pipeline computations on their vertexes. Consequently, it is convenient to apply this technique as early as possible within a 3D pipeline.
In FIG. 1 a block diagram of a geometry stage 111 is shown.
The structure of the geometry stage 111 can be better understood by referring to the different space coordinates that are used and implemented by its modules.
One of the primary roles of the pipelined graphic system is to transform coordinates from the 3D space used in an application scene/stage into the 2D space of the final display unit.
This transformation normally involves several intermediate coordinate systems, namely:                the modeling space: the modeling space is the space in which individual elements in a model are defined. These are usually the “natural” coordinates for an object. For example, a sphere may be defined as having unit radius and be centered at the origin in the modeling coordinates. Subsequent scaling and translation would position and resize the sphere appropriately within a scene;        
the world space: this represents the coordinate system of the final scene prior to viewing. OpenGL does not support an explicit notion of world space separate from view space, but some other graphics systems do (e.g., Direct3D, GKS 3D);
the view space: the view space has the synthetic camera as its origin, with the view direction along the z-axis. The view space coordinates are obtained from the modeling space via a model-view transformation. This coordinate system is sometimes referred to as “eye space”;
the normalized projection space: here the coordinates are projected into a canonical space via the projection transformation. It is a four dimensional space where each coordinate is represented by (x, y, z, w). The view volume represents the region of the model visible to the synthetic camera. It is bounded by six planes, for example z=0, z=w, y=−w, y=w, x=−w, x=w. A perspective projection results in a view volume that is a frustum;
the normalized device space: the normalized projection coordinates are converted into normalized device coordinates by dividing the first three coordinates (x, y, z) by the fourth w coordinate to obtain (x/w, y/w, z/w). The values of the resulting coordinates normally lie in the range −1 to 1 or from 0 to 1 in the case of the z coordinate;
the screen space: this space corresponds to the coordinates used to address the physical displaying device.
Thus, the geometry stage 111 comprises in the first place a model view transform module, indicated with a block 201.
The model view transform module 201 processes graphic information I in form of either triangles or their vertexes, and applies the model-view matrix to the vertexes.
Each vertex is multiplied by a 4×4 transform matrix in order to rotate or translate or scale or skew it. Each vertex is represented by four coordinates (x,y,z,w), where w=1.
Such a four coordinates system defines a homogeneous coordinate space and it is very convenient since points and vectors may be processed from a mathematical point of view with the same 4×4 matrices.
For example, a 3D transform is implemented as:P_new=MP_old+T where M is a matrix for rotation, scaling and skewing, T represents a translation operator, P_old indicates a coordinate of a vertex before transformation and P_new indicates a coordinate of the vertex after transformation.
It is not possible to have only a matrix in this case.
A four dimensional transform is implemented as:
      P_new    =                            [                                                    M                                            T                                                                    0                                            1                                              ]                ⁢        P_old            =                        M          1                ⁢        P_old              ⁢        
M1 indicates a rototranslation matrix and is possible to have only one of such matrixes. In this space the vertex positions are represented by quadruples of the type (x, y, z, 1), where the value 1 is allotted to the w coordinate for convenience, and vectors are represented by quadruples of the type (x, y, z, 0), which can be thought of as a point at infinity.
The output of the module 201 is a new vertex that contains the coordinates and normals transformed into view space. This space is suitable for lighting and fog calculations in a lighting module 202 and a fog module 203. The lighting module 202 performs a vertex operation to calculate color on the basis of the source light and its material property. The fogging module 203 performs a vertex operation to calculate its color knowing the fog characteristic.
A projection transform module 204 is provided further downstream to transform the coordinates in the view space into normalized projection coordinates. The projection transform module 204 is designed to process either vertexes or triangles.
The projection transform module 204 is followed by a primitive assembly module 205 that is responsible for assembling collections of vertexes into primitives. In this case, primitives are triangles. The primitive assembly module 205 must know what kinds of primitives are being assembled and how many vertexes have been submitted. For example, when assembling triangles, every third vertex triggers the creation of a new triangle and resets a vertex counter.
A frustum culling module 206 follows that operates by rejecting triangles lying outside the viewing region. Module 206 operates in normalized projection coordinates. A vertex having coordinates (x, y, z, w) is outside the frustum if: x>w, x<−w, y>w, y<−w, Z>w or z<−w, and a triangle lies outside of the frustum if all its vertexes lie on one side of the frustum (i.e., all above, below, to the left, right, in front or behind).
The pipelined frustum culling module 206 uses the notion of “outcodes” derived e.g., from the Cohen-Sutherland line clipping algorithm, as described for instance in the publication by I. Sutherland, “Reentrant polygon clipping” CACM, 17(1), January 1974, 32-42.
An outcode is here a 6-bit set of flags indicating the relationship of a vertex to the viewing frustum. If the outcodes of all three vertexes are zero, then the triangle is wholly within the frustum and must be retained. If the conjunction of the outcodes is non-zero, then all three vertexes must lie to one side of the frustum and the geometry must be culled. Otherwise the geometry must be retained, even though it may not actually overlap the view volume.
The outcodes are useful in the pipeline for a clipper module 207 that follows.
The clipper module 207, performs clipping to the viewing frustum as a pipeline of clips against its bounding planes. Clipping is necessary for several reasons. It is necessary for the efficiency of a rasterization stage 112 that follow geometric stage 111 to eliminate regions of polygons that lie outside the viewing frustum. Moreover, clipping against the near plane prevents vertexes with a coordinate w equal to zero being passed on to a subsequent perspective divide module 208. Clipping also bounds the coordinates that will be passed to the rasterization stage 112 allowing fixed precision operation in that module.
The clipping module as implemented increases the view volume slightly before applying the clips. This prevents artifacts from appearing at the edges of the screen, but implies that the rasterization stage 112 must cope with coordinates that are not strictly bounded by the device coordinates. The clips performed are against w>=near, z<=w, x>=−w′, x<=w′ and y<=w′, where w′ is w multiplied by a guard factor. Each clip is implemented as a specialization of a generic plane-clipping device. It is important to apply the clip to the near clipping plane first since this guarantees that further clips do not result in divide by zero.
The clipper module 207 is followed by the perspective divide module 208 already mentioned in the foregoing. The module 208 converts normalized projection coordinates into normalized device coordinates (x/w, y/w, z/w, 1).
Then, in the geometry stage 111 a back face culling module 209 is provided. Back face culling, as already mentioned, is a cheap and efficient method for eliminating geometry. In a polygonal solid, it is possible to enumerate each face such that the vertexes appear in a consistent winding order when they are visible. The choice of direction is arbitrary and OpenGL language, for instance, allows the desired order to be specified. Once the polygons have been projected into normalized device coordinates space, the sign of the cross product between two non co-linear edges establishes the orientation of a polygon. This can then be used to reject those polygons that face away from the viewer. The cross product need not consider the z coordinate since all z values are now equal to the distance to the projection plane. Thus, the test is very simple.
For concave solids, front facing polygons may not be all visible. Back-face culling is not appropriate for transparent objects where back faces may well be visible.
In the OpenGL pipeline, it is possible to assign different material properties to each side of a primitive. In this case, culling should be disabled. However, the back face calculation is still required in order to select the material that should be applied. In most pipeline configurations, this causes problems since it is not known at lighting time if a face is front or back facing necessitating double the lighting calculations and extra color information in each vertex.
Backface culling typically leads to roughly half of the polygons in a scene being eliminated. Since the decision is local to each polygon, it does not eliminate polygons that are obscured by other polygons.
Backface culling must be consistent with rasterization. If the back face culling module 209 eliminates polygons that should be rendered, then holes will appear in the final display.
Moreover, it is important to also cull polygons that should not be rendered. The latter case is more subtle. An incorrect implementation can lead to artifacts at the edge of transparent objects whose back-faces have not been properly culled.
The back face culling module 209 processes normalized device coordinates, even if it could operate equally well in screen space, where results are likely to be more consistent with the rasterizer. However in a circuital implementation, the calculations in the screen space would be fixed-point rather than floating-point as used in device coordinates. The only disadvantage is that viewport transforms in a subsequent viewport transform module 210 cannot be avoided.
The module 210 converts vertexes from normalized device coordinates into screen coordinates. The x and y coordinates are mapped to lie within a specified viewport and the z coordinate is mapped to lie within the range specified by the depth-range application programming interface (API) call. By default, z lies in the range 0 to 1.
In OpenGL, the rasterization stage 112 is designed to sample the geometry at the center of each pixel i.e., coordinates (0.5, 0.5), (1.5, 0.5)
From the point of view of the back face culling operation performed in the module 209, the geometry stage 111 shown in FIG. 1 effects a bidimensional back face culling into the screen space. Back face culling is performed after i.e., downstream the perspective division in module 208, i.e., only in two dimensions.
In FIG. 2 a schematic view of the vectors involved is shown.
Specifically, a triangle TR is shown along with its triangle normal vector TN, i.e., the vector that is normal to the triangle surface. An eye-point WP is shown associated to an eye-point vector V. A projected normal vector N, i.e., the projection of the normal vector TN in the direction of the eye-point vector V is also shown.
To calculate the normal projected vector N, two triangle edges T1 and T2 are necessary, since the normal projected vector N is the cross product between two triangle edge vectors. The sign of the normal projected vector N depends on the orientation of T1 and T2.
Conventionally, the sign is defined on the basis of the order of triangle vertexes. The first vector is from the first vertex toward the second vertex. The second vector is from the second vertex toward the third vertex. The eye-point vector V is drawn from the eye-point PW toward one of the triangle vertexes.
The projected normal vector N on the eye-point vector V is the inner (i.e., dot) product of the two vectors T1 and T2 divided by the module of the eye-point vector V. The division by the module of the eye-point vector V is, however, not necessary because this needed only for testing the sign of the projection vector N.
If the sign of the dot product operation is positive, then the triangle is visible.
In the case shown in FIG. 2, the normal vector TN is orthogonal to the screen and parallel to the eye-point vector V, so that the dot product is not necessary and only the z component of their cross (i.e., outer) product exists, namely the projected normal vector N.
If the sign of the z component is positive, then the triangle is visible.
Specifically, the first triangle edge vector T1 is notated TI=(T1x, T1y), while T2 is notated T2=(T2x, T2y) so that their cross product, corresponding to the projected normal vector N, is N=TI×T2=T1x T2y− T1yT2x.
This method requires only two multiplications and one algebraic sum for each triangle; however it is possible to perform culling only at the end stage of the pipeline: consequently, the triangles that are not visible are eliminated at a very late stage and the resulting pipeline is not efficient.
FIG. 3 shows a block diagram of a geometry stage 111a having a different arrangement of the various processing modules with respect to the geometry stage 111 described with reference to FIG. 1. In fact in the geometry stage 111a the model view transform module 201 is followed by the primitive assembly module 205, with the back face culling module 209 cascaded thereto. Downstream of the back face culling module 209, the projection transform module 204, the frustum culling module 206, the lighting 202 and fog 203 modules, the clipper module 207 and the perspective divide module 208 are arranged. The view port transform module 210 is finally located before (i.e., upstream) the rasterization stage 112.
In such a configuration of the geometry stage 111a, three-dimensional back face culling is performed in the view space. This arrangement involves a great number of operations, but makes it possible to perform back face culling at the beginning of the geometry stage 111a. 
The computation of the projected normal vector N is schematically shown in FIG. 4. The first triangle edge vector T1 is notated TI=(T1x, T1y, T1z) while the second triangle edge vector T2 is notated T2=(T2x, T2y, T2z). The cross product, corresponding to the projected normal vector N is thus:N=TI×T2=(T1yT2z−T1zT2y,T1xT2z−T1zT2x,T1xT2y−T1yT2x)
Nx, Ny, Nz are the components of the normal vector TN, and Vx, Vy, Vz are the components of the eye-point vector V. Consequently:N=TN·V=NxVx+NyVy+NzVz=Vx(T1yT2z−T1zT2y)+Vy(T1xT2z−T1zT2x)+Vz(T1xT2y−T1yT2x).
This arrangement, where triangles are culled at an early stage of the pipeline, requires nine multiplications and five algebraic sums for each triangle.
Thus, neither the geometry stage 111 of FIG. 1, nor the geometry stage 111a of FIG. 3 significantly reduce the overall mathematical operation count and number of primitives, i.e., triangles, to be processed by the 3D pipeline.